Software for Medical Devices: Six Practices You Should Not Overlook

Did you wake up one morning with a great yearning to help the world by designing a revolutionary medical device? Or are you a multibillion-dollar corporation with hundreds of medical devices on the market under your belt? Or perhaps somewhere in between? No matter what kind of company you are or what type of device you are manufacturing, software development will be a major part of your venture. Like it or not, devices that are not controlled by some form of software are the thing of the past.
 
When developing software for your medical device, many of the challenges you will face are quite standard in the software development world. There is simply no substitute for good developers, experienced architects, dedicated testing teams, a solid development process, and seasoned engineering management. For the purpose of this article, I will skip aspects related to software development in general and focus on issues specific to medical devices. The rest of this article is a broad overview of the challenges Auriga’s engineers have run into while working on dozens of medical device software projects of different shapes, forms, and sizes.
 
To set the playing field, let’s discuss who needs new medical device software and why. Many of Auriga’s customers already manufacture devices (did I mention this market’s stiff entry barriers?). Sooner or later, the experienced players run into the “end-of-life” situation with the device they are manufacturing. Either they face a shortage of the hardware components they have been using for many years, or they are being undermined by a shrewd competitor who has just released a new product with a slicker feature set. Regardless, the time comes when a new generation of the company’s product is due. It is important to point out that the product release cycle in the medical device world is very long (in many cases 5 to 7 years from inception to being used at a hospital), so the importance of strategic long-term planning cannot be overestimated. Occasionally, we see a revolutionary breakthrough device that defines a new market segment, but, again, the majority of situations involve a more functional, better-performing, user friendly generation of something that already exists. Does this sound familiar?
 
Given that we have determined who may benefit from Auriga’s experience in this field, I will now discuss some of the lessons we have learned over the years while working on medical device software projects.
 
1. Involve the software team early. Ensure your software development team has solid experience working with hardware, embedded software, and operating systems. Involve software engineers with this type of experience early, ideally at the hardware design stage. This will help you save significant time and money later on. In many cases, hardware specialists will put together a design that will “work,” but your system-level software team will tell you what hardware is optimal for a particular operating system. Armed with the knowledge of the hardware they are working with and knowing the boundaries early on, your embedded software experts will help answer questions such as:
 

• Do we need multiple CPUs?
• Do we need a real-time operating system?
• How should you approach board support package and hardware abstraction layer?
• What hardware drivers are available?
• What will need to be written from scratch?

 
You don’t want to compromise at this stage as the design mistakes made here may be lethal down the road. Whatever you do, don’t forget to invite your system-level software specialist to that meeting!
 
2. Your software team must have substantial IEC 62304 exposure. Invest in your software team’s training in the IEC 62304 and/or ISO 13485 standards. In recent years, these standards have de-facto become your bible for developing medical devices and software for medical devices. Obviously, your software development process is only part of your medical quality management system (MQMS). However, it is an essential part of it, so your software team must be well-integrated into your overall MQMS.
 
What could be more important than getting your team up to speed on these standards? Ensuring that the standards are being meticulously followed by the entire team. Following these standards requires a high level of maturity in your software team. Typically, these are people with years of experience in writing mission-critical software for industries such as aviation, medical, and defense. Our customers emphasize this frequently because this kind of maturity level can’t be built overnight.
 
3. Protect your algorithms by working with someone you trust. When you are manufacturing a device, what exactly is your IP? In many cases, it is not a new, multi-core CPU, sexy touchscreens, or cute marketing campaigns. More often than not, your IP is your mathematical algorithms and their software implementation. Successful product teams treat their algorithms as their most precious treasure. We’ve encountered situations where we have received algorithms as encrypted blocks (and we don’t take this as distrust). We’ve also been in situations where we were hired to actually develop a mathematical algorithm from the ground up. Both extremes take place in real life, as well as situations in the middle. However, whatever you do, treat your medical algorithms with respect. Only work with software teams you trust, and then protect yourself through an adequate legal process.
 
4. Keep the user experience simple and reliable. Usability is an essential aspect of your new device. Simply put, you may have the most reliable device on the market, but it won’t sell if it looks like something our grandparents used, does not give doctors the information they need at their fingertips, or does not adequately alert nurses about an urgent issue. However, don’t overdo it! Keep in mind that your device must remain simple, straightforward to use, and reliable. A new, cool feature that appeared on your iPhone out of the blue last month does not necessarily belong on your medical device. Whatever you do, your users will have some of the most difficult jobs in the world (saving people’s lives). They work under tremendous pressure. As software vendors, we need to do whatever we can to simplify their jobs, not complicate them.
 
5. Upgrading your device does not mean a complete redesign. As discussed earlier, many of our large customers have a solid device on the market (or 50 devices), but they are facing the challenge of facelifting the device, making it more modern-looking and user-friendly. Recently, we worked on such a project. The customer felt like the device was functional and “worked fine,” but “felt dated.” One of the possible solutions was to split the device into two separate devices. The original Class C (live critical) device stayed nearly unchanged. It kept the most critical indicators and controls. The additional (separate) device was a touchscreen with new software. It provided convenience, non-essential reporting, and a modern look and feel. The second device was not Class C; it just communicated with the original Class C device. This approach helped our customer save a tremendous amount of time and money during FDA approvals.
 
6. Plan for device interoperability from day one. The days when two long-haired nerds and a dog could put together a serious medical device and install it at a local hospital are long gone. Of course, there is an exception to every rule, but most modern medical devices are highly robust machines with multiple layers of software running on them. Moreover, they need to be able to communicate with a variety of other devices and hospital information systems that may be from the same vendor or a variety of different vendors. The devices may need to communicate with each other over different protocols, from direct USB connections to Wi-Fi to Bluetooth to who-knows-what communication protocols that will be available next year. This raises the “interoperability” aspect of medical device software development. Your engineering teams need to ensure your hardware and software are designed for interoperability. Familiarizing yourself with the HL7 standard might be a great place to start!
 
Needless to say, this article only touches the tip of the medical device software iceberg (or, rather, several tips). Nevertheless, if it made you think about how to organize your projects, it has accomplished its goal. Regardless of whether you decide to build your development team internally or involve an external development company, do not compromise on these recommendations. Remember that we are considering a medical device, so someone’s life may be on the line!
 

---

In his role of executive vice president of Auriga, Yuri Kirkel is responsible for defining corporate strategy, marketing, and business development. He brings to Auriga about 20 years of successful leadership with both IT services and software product companies. In his previous position, Kirkel was SVP of professional services at an enterprise CMS and advertising solutions developer. He holds an M.B.A. from Northeastern University in Boston.